CI only for yas-run/yas#87 (receive budget, on #85) — do not merge - #41

…as-run#88)

* Keep a command's output head and tail, drop its middle at pipe speed

SPAWN_KEEP_OUTPUT (32), with REPORT_EXIT and SPAWN extension tag 4
[head_bytes, tail_bytes] (the tail at most 1 MiB), sends only the head and
the tail of each output stream. What comes between is dropped as the
server reads it, never held for the client's credit, so a command writing
far more than its client keeps runs at the speed of its pipe instead of
one window per round trip.

The cuts fall between characters as a WHATWG UTF-8 decoder with
replacement reads the whole stream (a JavaScript TextDecoder, Rust's
from_utf8_lossy), so decoding the head and the tail gives exactly the
characters they have within it. The EXIT event says what was dropped of
each stream (extension tags 1 and 2, OutputElision: offset, bytes, lines,
code points, UTF-16 units), so a client can say how much it did not get in
the units it counts.

The output reader waits for the owner only while the head goes out, keeps
the last tail_bytes in a ring, and sends them at the stream's end, or
before the exit is reported when the stream outlives it (a residue past
its grace, TERMINATE, a lost owner, a forced cleanup): flush_kept.

yas-client: Command::keep_output(head, tail), set where the server offers
it; Process::elided(stderr) once the exit came.

* Keep the elision in Process::output; gate mod process again

Review of yas-run#88: Output had no place for what KEEP_OUTPUT dropped, and
output() takes the process, so a kept command's head and tail came joined
with nothing to say a middle was missing. Output.elided now carries it
(the test's helper is output_limited again). And the new mod output_keep
line took mod process's #[cfg(any(unix, windows))].

* Check an output elision's UTF-16 bound without overflowing

protocol-fuzz found OutputElision::decode multiplying a decoded code point
count by two, which panics past u64::MAX / 2. Saturate instead: a count that
wide bounds nothing it could hold. Test the five counts' rules, prefixes, and
the widest values.

…m it

Every stdout and stderr stream holds its window of the session's receive
budget while it is open, whether it writes or not, and yas-client divides
three quarters of that budget between the server's per-session maximum of
processes. The budget was always 16 MiB (RECOMMENDED_BUFFERED): a client
that runs 256 processes a session got 24 KiB windows, and over a network a
stream carries about a window a round trip (20 MB took 88 s at 100 ms). A
wider window per command instead oversubscribes the budget: once it is all
held, a new stream gets no credit until another lets go.

HelloOptions::receive_budget (16 MiB by default, at most 1 GiB) is the
HELLO receive max_buffered this client declares; Client::receive_budget
says it, and default_process_window divides it instead of the constant.
At 256 processes in 256 MiB each stream gets 384 KiB, and they all fit.
Servers already honour a peer's budget above 16 MiB (their outbound credit
is the peer's max_buffered).

Test (client_host): a_wider_receive_budget_fits_every_process_window: at
256 processes a session, 16 MiB gives 24 KiB windows and 256 MiB 384 KiB;
with 255 quiet processes holding theirs (510 streams, 191 MiB), one more
gets all of three windows of output at once. With the same windows in
16 MiB, that command gets no credit (checked: it waited past 30 s).

Review of yas-run#87: NativeClient's queue of frames parked while a caller waits
for another stayed capped at 16 MiB and 1,024 frames, so a client that
declared a wider budget, and was sent within it, failed its session with
"native YAS peer exceeded the bounded pending-frame queue".

The cap is now the declared budget in bytes, and one frame per 16 KiB of
it in frames (at least 1,024, the default's). The new test parks 17 MiB
in 1,372 frames within a 64 MiB budget; capping either bound at the
default's makes it fail.